1
2
Il prossimo
No.
Il JSON è solo dati e, se includi un commento, saranno anche dati.
Potresti avere un elemento dati designato chiamato "_comment" (o qualcosa del genere) che dovrebbe essere ignorato dalle app che utilizzano i dati JSON.
Probabilmente sarebbe meglio avere il commento nei processi che genera / riceve il JSON, poiché dovrebbero sapere in anticipo quali saranno i dati JSON, o almeno la struttura di essi.
Ma se hai deciso di:
{
"_comment": "il testo del commento va qui ...",
"glossario": {
"titolo": "glossario di esempio",
"GlossDiv": {
"titolo": "S",
"GlossList": {
"GlossEntry": {
"ID": "SGML",
"SortAs": "SGML",
"GlossTerm": "Linguaggio di markup generalizzato standard",
"Acronimo": "SGML",
"Abbrev": "ISO 8879: 1986",
"GlossDef": {
"para": "Un meta-linguaggio di markup, utilizzato per creare linguaggi di markup come DocBook.",
"GlossSeeAlso": ["GML", "XML"]
},
"GlossSee": "markup"
}
}
}
}
}
|
No, i commenti nel formato //… o / *… * / non sono consentiti in JSON. Questa risposta si basa su:
https://www.json.org
RFC 4627:
Il tipo di supporto application / json per JavaScript Object Notation (JSON)
RFC 8259 Il formato di scambio dati JSON (JavaScript Object Notation) (sostituisce RFC 4627, 7158, 7159)
|
Includere commenti se si sceglie; eliminarli con un minifier prima di analizzarli o trasmetterli.
Ho appena rilasciato JSON.minify () che rimuove i commenti e gli spazi bianchi da un blocco di JSON e lo rende JSON valido che può essere analizzato. Quindi, potresti usarlo come:
JSON.parse (JSON.minify (my_str));
Quando l'ho rilasciato, ho ricevuto un enorme contraccolpo di persone che non erano d'accordo nemmeno con l'idea, quindi ho deciso di scrivere un post sul blog completo sul perché i commenti hanno senso in JSON. Include questo commento notevole dal creatore di JSON:
Supponi di utilizzare JSON per mantenere i file di configurazione, che desideri annotare. Vai avanti e inserisci tutti i commenti che ti piacciono. Quindi indirizzalo attraverso JSMin prima di passarlo al tuo parser JSON. - Douglas Crockford, 2012
Si spera che sia utile a coloro che non sono d'accordo con il motivo per cui JSON.minify () potrebbe essere utile.
|
I commenti sono stati rimossi da JSON in base alla progettazione.
Ho rimosso i commenti da JSON perché ho visto che le persone li usavano per mantenere le direttive di analisi, una pratica che avrebbe distrutto l'interoperabilità. So che la mancanza di commenti rende alcune persone tristi, ma non dovrebbe.
Supponi di utilizzare JSON per mantenere i file di configurazione, che desideri annotare. Vai avanti e inserisci tutti i commenti che ti piacciono. Quindi indirizzalo attraverso JSMin prima di passarlo al tuo parser JSON.
Fonte: dichiarazione pubblica di Douglas Crockford su G +
|
JSON non supporta i commenti. Inoltre, non è mai stato concepito per essere utilizzato per i file di configurazione in cui sarebbero necessari commenti.
Hjson è un formato di file di configurazione per gli esseri umani. Sintassi rilassata, meno errori, più commenti.
Vedi hjson.github.io per le librerie JavaScript, Java, Python, PHP, Rust, Go, Ruby, C ++ e C #.
|
DISCLAIMER: LA VOSTRA GARANZIA È NULLA
Come è stato sottolineato, questo hack sfrutta l'implementazione delle specifiche. Non tutti i parser JSON capiranno questo tipo di JSON. I parser in streaming in particolare si strozzeranno.
È una curiosità interessante, ma in realtà non dovresti usarlo per niente. Di seguito è la risposta originale.
Ho trovato un piccolo trucco che ti consente di inserire commenti in un file JSON che non influirà sull'analisi o altererà i dati rappresentati in alcun modo.
Sembra che quando si dichiara un oggetto letterale è possibile specificare due valori con la stessa chiave e l'ultimo ha la precedenza. Che ci crediate o no, risulta che i parser JSON funzionano allo stesso modo. Quindi possiamo usarlo per creare commenti nel JSON sorgente che non saranno presenti in una rappresentazione di oggetti analizzati.
({a: 1, a: 2});
// => Oggetto {a: 2}
Object.keys (JSON.parse ('{"a": 1, "a": 2}')). Length;
// => 1
Se applichiamo questa tecnica, il tuo file JSON commentato potrebbe avere questo aspetto:
{
"api_host": "Il nome host del tuo server API. Puoi anche specificare la porta.",
"api_host": "hodorhodor.com",
"retry_interval": "L'intervallo in secondi tra i nuovi tentativi di chiamate API non riuscite",
"retry_interval": 10,
"auth_token": "Il token di autenticazione. È disponibile nella dashboard per sviluppatori in" Impostazioni "",
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"favorite_numbers": "Un array contenente i miei numeri preferiti di tutti i tempi",
"favorite_numbers": [19, 13, 53]
}
Il codice sopra è JSON valido. Se lo analizzi, otterrai un oggetto come questo:
{
"api_host": "hodorhodor.com",
"retry_interval": 10,
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"favorite_numbers": [19,13,53]
}
Il che significa che non c'è traccia dei commenti e non avranno strani effetti collaterali.
Buon hacking!
|
Considera l'utilizzo di YAML. È quasi un superset di JSON (praticamente tutto il JSON valido è YAML valido) e consente commenti.
|
Non puoi. Almeno questa è la mia esperienza da una rapida occhiata a json.org.
JSON ha la sua sintassivisualizzato in quella pagina. Non c'è alcuna nota sui commenti.
|
I commenti non sono uno standard ufficiale, sebbene alcuni parser supportino i commenti in stile C ++. Uno che uso è JsonCpp. Negli esempi c'è questo:
// Opzioni di configurazione
{
// Codifica predefinita per il testo
"codifica": "UTF-8",
// Plug-in caricati all'avvio
"plug-in": [
"pitone",
"c ++",
"rubino"
],
// Dimensione rientro tabulazione
"indent": {"length": 3, "use_space": true}
}
jsonlint non lo convalida. Quindi i commenti sono un'estensione specifica del parser e non uno standard.
Un altro parser è JSON5.
Un'alternativa a JSON TOML.
Un'ulteriore alternativa è jsonc.
L'ultima versione di nlohmann / json ha un supporto opzionale per ignorare i commenti sull'analisi.
|
Dovresti invece scrivere uno schema JSON. Lo schema JSON è attualmente una bozza di specifica Internet proposta. Oltre alla documentazione, lo schema può essere utilizzato anche per convalidare i dati JSON.
Esempio:
{
"description": "Una persona",
"tipo": "oggetto",
"proprietà":
{
"nome":
{
"tipo": "stringa"
},
"età":
{
"tipo": "intero",
"massimo": 125
}
}
}
È possibile fornire la documentazione utilizzando l'attributo dello schema di descrizione.
|
Se stai usando Jackson come parser JSON, ecco come lo abiliti per consentire i commenti:
ObjectMapper mapper = new ObjectMapper (). Configure (Feature.ALLOW_COMMENTS, true);
Quindi puoi avere commenti come questo:
{
chiave: "valore" // Commento
}
E puoi anche avere commenti che iniziano con # impostando:
mapper.configure (Feature.ALLOW_YAML_COMMENTS, true);
Ma in generale (come risposto prima) la specifica non consente commenti.
|
Ecco cosa ho trovato nella documentazione di Google Firebase che ti permette di inserire commenti in JSON:
{
"//": "Alcuni browser lo useranno per abilitare le notifiche push.",
"//": "È lo stesso per tutti i progetti, questo non è l'ID mittente del progetto",
"gcm_sender_id": "1234567890"
}
|
NO. JSON supportava i commenti, ma sono stati abusati e rimossi dallo standard.
Dal creatore di JSON:
Ho rimosso i commenti da JSON perché ho visto che le persone li usavano per mantenere le direttive di analisi, una pratica che avrebbe distrutto l'interoperabilità. So che la mancanza di commenti rende alcune persone tristi, ma non dovrebbe. - Douglas Crockford, 2012
Il sito JSON ufficiale è su JSON.org. JSON è definito come uno standard da ECMA International. C'è sempre un processo di petizione per la revisione degli standard. È improbabile che le annotazioni vengano aggiunte allo standard JSON per diversi motivi.
JSON by design è un'alternativa facilmente decodificata (analizzata dall'uomo) a XML. È semplificato al punto che le annotazioni non sono necessarie. Non è nemmeno un linguaggio di markup. L'obiettivo è la stabilità e l'interoperabilità.
Chiunque capisca la relazione "ha-a" dell'orientamento agli oggetti può comprendere qualsiasi struttura JSON: questo è il punto. È solo un grafico aciclico diretto (DAG) con tag di nodo (coppie chiave / valore), che è una struttura dati quasi universale.
Questa unica annotazione richiesta potrebbe essere "// Questi sono tag DAG". I nomi delle chiavi possono essere tanto informativi quanto richiesto, consentendo arità semantica arbitraria.
Qualsiasi piattaforma può analizzare JSON con poche righe di codice. XML richiede complesse librerie OO che non sono utilizzabili su molte piattaforme.
Le annotazioni renderebbero JSON meno interoperabile. Non c'è semplicemente nient'altro da aggiungere, a meno che ciò di cui hai veramente bisogno non sia un linguaggio di markup (XML), e non ti importa se i tuoi dati persistenti vengono facilmente analizzati.
MA come ha osservato anche il creatore di JSON, c'è sempre stato il supporto della pipeline JS per i commenti:
Vai avanti e inserisci tutti i commenti che ti piacciono.
Quindi indirizzalo attraverso JSMin prima di passarlo al tuo parser JSON. - Douglas Crockford, 2012
|
Se il tuo file di testo, che è una stringa JSON, verrà letto da qualche programma, quanto sarebbe difficile rimuovere i commenti in stile C o C ++ prima di usarlo?
Risposta: sarebbe una linea. Se lo fai, i file JSON potrebbero essere utilizzati come file di configurazione.
|
Se stai usando la libreria Newtonsoft.Json con ASP.NET per leggere / deserializzare puoi usare i commenti nel contenuto JSON:
// "nome": "stringa"
// "id": int
o
/* Questo è un
esempio di commento * /
PS: i commenti su una sola riga sono supportati solo con 6+ versioni di Newtonsoft Json.
Nota aggiuntiva per le persone che non sanno pensare fuori dagli schemi: utilizzo il formato JSON per le impostazioni di base in un'applicazione Web ASP.NET che ho creato. Ho letto il file, lo converto nell'oggetto impostazioni con la libreria Newtonsoft e lo utilizzo quando necessario.
Preferisco scrivere commenti su ogni singola impostazione nel file JSON stesso e non mi interessa davvero dell'integrità del formato JSON fintanto che la libreria che uso è a posto.
Penso che questo sia un modo "più facile da usare / capire" rispetto alla creazione di un file "settings.README" separato e alla spiegazione delle impostazioni in esso.
Se hai un problema con questo tipo di utilizzo; scusa, il genio è fuori dalla lampada. Le persone troverebbero altri usi perFormato JSON e non puoi farci niente.
|
L'idea alla base di JSON è fornire un semplice scambio di dati tra le applicazioni. Questi sono in genere basati sul Web e il linguaggio è JavaScript.
In realtà non consente commenti in quanto tali, tuttavia, passare un commento come una delle coppie nome / valore nei dati funzionerebbe sicuramente, anche se quei dati dovrebbero ovviamente essere ignorati o gestiti specificamente dal codice di analisi.
Detto questo, non è intenzione che il file JSON contenga commenti nel senso tradizionale. Dovrebbero essere solo i dati.
Dai un'occhiata al sito Web JSON per maggiori dettagli.
|
JSON non supporta i commenti in modo nativo, ma puoi creare il tuo decoder o almeno il preprocessore per eliminare i commenti, va benissimo (a patto che tu ignori i commenti e non li usi per guidare il modo in cui la tua applicazione dovrebbe elaborare i dati JSON ).
JSON non ha commenti. Un codificatore JSON NON DEVE emettere commenti.
Un decodificatore JSON PU accettare e ignorare i commenti.
I commenti non dovrebbero mai essere usati per trasmettere qualcosa di significativo. Questo è
a cosa serve JSON.
Cfr: Douglas Crockford, autore di JSON spec.
|
Ho appena riscontrato questo per i file di configurazione. Non voglio usare XML (verboso, graficamente, brutto, difficile da leggere), o formato "ini" (nessuna gerarchia, nessuno standard reale, ecc.) O formato "Proprietà" Java (come .ini).
JSON può fare tutto ciò che possono fare, ma è molto meno dettagliato e più leggibile dall'uomo e gli analizzatori sono facili e onnipresenti in molte lingue. È solo un albero di dati. Ma i commenti fuori banda sono spesso una necessità per documentare le configurazioni "predefinite" e simili. Le configurazioni non devono mai essere "documenti completi", ma alberi di dati salvati che possono essere leggibili dall'uomo quando necessario.
Immagino che si possa usare "#": "comment", per JSON "valido".
|
Dipende dalla tua libreria JSON. Json.NET supporta commenti in stile JavaScript, / * commment * /.
Vedi un'altra domanda su Stack Overflow.
|
JSON ha molto senso per i file di configurazione e altri usi locali perché è onnipresente e perché è molto più semplice di XML.
Se le persone hanno validi motivi per non avere commenti in JSON durante la comunicazione dei dati (validi o meno), forse JSON potrebbe essere diviso in due:
JSON-COM: JSON in rete o regole che si applicano durante la comunicazione di dati JSON.
JSON-DOC: documento JSON o JSON nei file o localmente. Regole che definiscono un documento JSON valido.
JSON-DOC consentirà i commenti e potrebbero esistere altre piccole differenze come la gestione degli spazi. I parser possono facilmente convertire da una specifica all'altra.
Per quanto riguarda l'osservazione fatta da Douglas Crockford su questo tema (citato da @Artur Czajka)
Supponi di utilizzare JSON per mantenere i file di configurazione, che desideri annotare. Vai avanti e inserisci tutti i commenti che ti piacciono. Quindi indirizzalo attraverso JSMin prima di passarlo al tuo parser JSON.
Stiamo parlando di un problema di file di configurazione generico (cross language / piattaforma), e sta rispondendo con un'utilità specifica di JS!
Sicuramente un minify specifico JSON può essere implementato in qualsiasi lingua,
ma standardizzalo in modo che diventi onnipresente tra i parser in tutte le lingue e piattaforme in modo che le persone smettano di sprecare il loro tempo senza la funzionalità perché hanno buoni casi d'uso per essa, esaminano il problema nei forum online e convincono le persone a dire loro che è una cattiva idea o suggerendo che è facile implementare l'eliminazione dei commenti dai file di testo.
L'altro problema è l'interoperabilità. Supponiamo di avere una libreria o un'API o qualsiasi tipo di sottosistema a cui sono associati alcuni file di configurazione o di dati. E questo sottosistema lo è
accessibile da diverse lingue. Allora vai a dire alla gente: a proposito
non dimenticare di eliminare i commenti dai file JSON prima di passarli al parser!
|
Se usi JSON5 puoi includere commenti.
JSON5 è un'estensione proposta a JSON che mira a rendere più facile per gli esseri umani scrivere e mantenere a mano. Lo fa aggiungendo alcune funzionalità di sintassi minime direttamente da ECMAScript 5.
|
Il toolkit JavaScript Dojo Toolkit (almeno a partire dalla versione 1.4), ti consente di includere commenti nel tuo JSON. I commenti possono essere nel formato / * * /. Dojo Toolkit utilizza JSON tramite la chiamata dojo.xhrGet ().
Altri toolkit JavaScript potrebbero funzionare in modo simile.
Questo può essere utile quando si sperimentano strutture di dati alternative (o anche elenchi di dati) prima di scegliere un'opzione finale.
|
JSON non è un protocollo con frame. È un formato senza lingua. Quindi il formato di un commento non è definito per JSON.
Come molte persone hanno suggerito, ci sono alcuni trucchi, ad esempio chiavi duplicate o una chiave _comment specifica che puoi usare. Tocca a voi.
|
Puoi avere commenti in JSONP, ma non in JSON puro. Ho appena passato un'ora cercando di far funzionare il mio programma con questo esempio di Highcharts: http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?
Se segui il link, vedrai
? (/ * AAPLdati OHLC storici dall'API di Google Finance * /
[
/ * Maggio 2006 * /
[1147651200000,67.79],
[1147737600000,64.98],
...
[1368057600000,456.77],
[1368144000000,452.97]
]);
Dato che avevo un file simile nella mia cartella locale, non c'erano problemi con la politica della stessa origine, quindi ho deciso di utilizzare JSON puro ... e, ovviamente, $ .getJSON non funzionava silenziosamente a causa dei commenti.
Alla fine ho appena inviato una richiesta HTTP manuale all'indirizzo sopra e mi sono reso conto che il tipo di contenuto era text / javascript poiché, beh, JSONP restituisce JavaScript puro. In questo caso sono ammessi commenti. Ma la mia applicazione ha restituito il tipo di contenuto application / json, quindi ho dovuto rimuovere i commenti.
|
Questa è una domanda "puoi". Ed ecco una risposta "sì".
No, non dovresti utilizzare membri oggetto duplicati per inserire i dati del canale laterale in una codifica JSON. (Vedi "I nomi all'interno di un oggetto DOVREBBE essere univoci" nella RFC).
E sì, potresti inserire commenti sul JSON, che potresti analizzare.
Ma se vuoi un modo per inserire ed estrarre dati arbitrari dal canale laterale in un JSON valido, ecco una risposta. Sfruttiamo la rappresentazione non univoca dei dati in una codifica JSON. Ciò è consentito * nella sezione due dell'RFC sotto "gli spazi bianchi sono consentiti prima o dopo uno qualsiasi dei sei caratteri strutturali".
* L'RFC afferma solo "gli spazi bianchi sono consentiti prima o dopo uno qualsiasi dei sei caratteri strutturali", senza menzionare esplicitamente stringhe, numeri, "false", "true" e "null". Questa omissione viene ignorata in TUTTE le implementazioni.
Innanzitutto, canonicalizza il tuo JSON minimizzandolo:
$ jsonMin = json_encode (json_decode ($ json));
Quindi codifica il tuo commento in binario:
$ hex = unpack ('H *', $ commento);
$ commentBinary = base_convert ($ hex [1], 16, 2);
Quindi imposta il tuo binario:
$ steg = str_replace ('0', '', $ commentBinary);
$ steg = str_replace ('1', "\ t", $ steg);
Ecco il tuo output:
$ jsonWithComment = $ steg. $ jsonMin;
|
Disclaimer: questo è sciocco
In realtà c'è un modo per aggiungere commenti e rimanere all'interno delle specifiche (non è necessario alcun parser aggiuntivo). Tuttavia, non si tradurrà in commenti leggibili dall'uomo senza alcun tipo di analisi.
Potresti abusare di quanto segue:
Sono consentiti spazi non significativi prima o dopo qualsiasi token.
Lo spazio bianco è qualsiasi sequenza di uno o più dei seguenti codici
punti: tabulazione carattere (U + 0009), avanzamento riga (U + 000A), carrello
ritorno (U + 000D) e spazio (U + 0020).
In un modo hacky, puoi abusarne per aggiungere un commento. Ad esempio: inizia e termina il tuo commento con una scheda. Codifica il commento in base3 e usa gli altri caratteri di spazio per rappresentarli. Per esempio.
010212 010202 011000 011000 011010 001012 010122 010121 011021 010202 001012 011022 010212 011020 010202 010202
(ciao base tre in ASCII) Ma invece di 0 usa lo spazio, per 1 usa l'avanzamento riga e per 2 usa il ritorno a capo.
Questo ti lascerà con molti spazi illeggibili (a meno che tu non crei un plugin IDE per codificarlo / decodificarlo al volo).
Non l'ho mai nemmeno provato, per ovvi motivi e nemmeno tu dovresti.
|
JSON non consente commenti, di per sé. Il ragionamento è assolutamente sciocco, perché puoi usare JSON stesso per creare commenti, il che evita completamente il ragionamento e carica lo spazio dati del parser senza una buona ragione per esattamente lo stesso risultato e potenziali problemi, come sono: un JSON file con commenti.
Se provi a inserire commenti (usando // o / * * / o # per esempio), alcuni parser falliranno perché questo non è strettamente
all'interno della specifica JSON. Quindi non dovresti mai farlo.
Qui, ad esempio, dove il mio sistema di manipolazione delle immagini ha salvato notazioni di immagini e alcune informazioni di base formattate (commenti) relative ad esse (in basso):
{
"Notazioni": [
{
"anchorX": 333,
"anchorY": 265,
"areaMode": "Ellipse",
"extentX": 356,
"extentY": 294,
"opacità": 0,5,
"text": "Area ellittica in alto",
"textX": 333,
"textY": 265,
"title": "Notazione 1"
},
{
"anchorX": 87,
"anchorY": 385,
"areaMode": "Rectangle",
"extentX": 109,
"extentY": 412,
"opacità": 0,5,
"text": "Rect area \ non bottom",
"textX": 98,
"textY": 385,
"title": "Notazione 2"
},
{
"anchorX": 69,
"anchorY": 104,
"areaMode": "Polygon",
"extentX": 102,
"extentY": 136,
"opacità": 0,5,
"pointList": [
{
"i": 0,
"x": 83,
"y": 104
},
{
"i": 1,
"x": 69,
"y": 136
},
{
"i": 2,
"x": 102,
"y": 132
},
{
"i": 3,
"x": 83,
"y": 104
}
],
"text": "Poligono semplice",
"textX": 85,
"textY": 104,
"title": "Notazione 3"
}
],
"imageXW": 512,
"imageYW": 512,
"imageName": "lena_std.ato",
"tinyDocs": {
"c01": "Dati notazione immagine JSON:",
"c02": "-------------------------",
"c03": "",
"c04": "Questi dati contengono notazioni di immagini e area correlata",
"c05": "informazioni sulla selezione che forniscono un mezzo per un",
"c06": "galleria di immagini per visualizzare notazioni ellittiche,",
"c07": "indicazioni di aree rettangolari, poligonali o a mano libera",
"c08": "su un'immagine mostrata a un visitatore della galleria.",
"c09": "",
"c10": "Le posizioni X e Y sono tutte nell'immaginespazio. L'immagine",
"c11": "la risoluzione è data come imageXW e imageYW, che",
"c12": "da utilizzare per ridimensionare le aree di notazione al loro corretto",
"c13": "posizioni e dimensioni per la visualizzazione dell'immagine",
"c14": "indipendentemente dalla scala.",
"c15": "",
"c16": "Per Ellipses, anchor è il centro dell'ellisse",
"c17": "e le estensioni corrispondono rispettivamente ai raggi X e Y.",
"c18": "",
"c19": "Per i rettangoli, l'ancora è in alto a sinistra e",
"c20": "le estensioni sono in basso a destra.",
"c21": "",
"c22": "Per i modi area Mano libera e Poligono, il pointList",
"c23": "contiene una serie di punti XY numerati. Se l'area",
"c24": "è chiuso, l'ultimo punto sarà lo stesso di",
"c25": "prima, quindi tutto ciò di cui devi preoccuparti è disegnare",
"c26": "linee tra i punti nell'elenco. Ancoraggio ed estensione",
"c27": "sono impostati in alto a sinistra e in basso a destra dell'indicato",
"c28": "regione e può essere utilizzato come un rettangolo semplicistico",
"c29": "rileva la posizione del passaggio del mouse su questi tipi",
"c30": "di aree.",
"c31": "",
"c32": "Le posizioni textx e texty forniscono il posizionamento di base",
"c33": "informazioni per aiutarti a individuare le informazioni di testo",
"c34": "in una posizione ragionevole associata all'area",
"c35": "indicazione.",
"c36": "",
"c37": "L'opacità è un valore compreso tra 0 e 1, dove .5 rappresenta",
"c38": "uno sfondo opaco al 50% e 1.0 rappresenta uno sfondo completamente opaco",
"c39": "contesto. La raccomandazione è che le regioni siano disegnate",
"c40": "solo se l'utente posiziona il puntatore sull'immagine",
"c41": "e che sia disegnato il testo associato alle regioni",
"c42": "solo se l'utente posiziona il puntatore sopra l'indicato",
"c43": "regione".
}
}
|
Stiamo usando strip-json-comments per il nostro progetto. Supporta qualcosa come:
/ *
* Descrizione
* /
{
// arcobaleni
"unicorno": / * ❤ * / "torta"
}
Semplicemente installa npm - salva i commenti strip-json per installarlo e usarlo come:
var strip_json_comments = require ('strip-json-comments')
var json = '{/ * arcobaleni * / "unicorn": "cake"}';
JSON.parse (strip_json_comments (json));
// => {unicorno: 'cake'}
|
Nel mio caso, ho bisogno di utilizzare i commenti a scopo di debug subito prima dell'output della struttura JSON. Quindi ho deciso di utilizzare le informazioni di debug nell'intestazione HTTP, per evitare di rompere il client:
header ("My-Json-Comment: Sì, lo so che è una soluzione alternativa ;-)");
|
Per tagliare un elemento JSON in parti aggiungo le righe "commento fittizio":
{
"#############################" : "Parte 1",
"data1": "valore1",
"data2": "valore2",
"#############################" : "Parte 2",
"data4": "valore3",
"data3": "valore4"
}
|
1
2
Il prossimo
Domanda molto attiva. Guadagna 10 punti reputazione per rispondere a questa domanda. Il requisito di reputazione aiuta a proteggere questa domanda dallo spam e dalle attività di mancata risposta.
Non è la risposta che stai cercando? Sfoglia altre domande taggate json commenti o fai la tua domanda.